In a typical disk storage subsystem, the storage space of the physical disks attached to the storage subsystem is configured to appear to a host system as a collection of separately addressable logical storage volumes. When the host system requests access to a data element of a logical volume, the storage subsystem maps the address of the requested data element on the logical volume to a corresponding data element on an attached physical device and directs the access request to the correct physical location. Thus, logical devices or volumes are emulated by the storage subsystem and devices appear to the host system as a natively attached physical device. The host, therefore, is able to access logical devices or volumes independent of the physical space containing the actual data. For example, a single large physical storage space may be configured as several smaller virtual (logical) spaces. When the physical storage space comprises multiple units of media, a logical volume may span more than one such unit. Additionally, physical storage may be configured as logical volumes for use by multiple hosts and/or multiple operating systems. Details and other benefits of the virtualization of logical volumes are well known and will not be described further herein.
The virtualized logical volumes may be comprised of any type of physical storage including, without limitation, electronic memory (such as RAM or solid state memory), hard disks, RAID arrays, tape cartridges, optical discs and other media. Removable media may be (but need not be) contained with an automated data storage library.
In some storage subsystems, metadata is generated when data is written to storage and checked when the data is later read to ensure that the correct data element has been fetched. For example, when a data block is written to a SCSI disk, a sequence number comprising the two low-order bytes of the logical address of the block may be stored with the data itself. The sequence number is retrieved when the data is read and compared with the two low-order bytes of the logical address used to access the target block. If the data block was stored in the wrong location or if the wrong block was retrieved, the error will typically be detected.
In some storage subsystems, physical storage, such as hard disks, is virtualized by dividing the physical space in to fixed size “pages”. Pages are then logically concatenated to create storage space for an emulated logical device or volume. The strength of sequence number verification may by compromised if the number of blocks in a page is an integral power of 2. For example, when the sequence numbers are generated from the two low-order bytes (16 bits) of the logical block addresses, there are 216=64 KB possible sequence numbers. Table 1 illustrates a prior art arrangement of logical blocks (LV Blocks) in which, for convenience, each page has eight blocks and sequence number are 2 bits (ranging from 0-3).
TABLE 1LOGICAL VOLUME 0 (Prior Art)ArrayLV BlockSequencePageArrayNo.No.No.Block No.0000110122023303400451056206730780109111102121131312014131151421615317160201712118222193232002421125222262332724030
Because the number of blocks in a page is a power of 2 and exceeds the range of the sequence numbers, all pages begin and end with the same sequence number. On the other hand, if the number of blocks in a page is less than the range of sequence numbers, the progression of sequence numbers within the pages will still repeat periodically, but over some number of pages rather than at each page. In either configuration, such “aliasing” of sequence numbers among the blocks may result in a sequence number check failing to detect an error: a miscalculation of which page is mapped to page A of volume B might cause access instead to page C of volume D. Similarly, an attempt to access a block stored in position F of page A of volume B may instead mistakenly access the block stored in position F of page C of volume B. In both instances, blocks have the same sequence number and an incorrect access (or storage) would go undetected.
Several solutions have been suggested. In one, the page sizes could be created with a number of blocks which is not an exact power of 2. However, because volumes are typically an exact multiple of a power of 2 in size, alignment to page boundaries, which prevents wasted space, becomes difficult. Moreover, arithmetic in block address calculations becomes more complicated.
In another suggestion, one or more additional fields, such as the page number, may be included in the metadata and stored with the existing sequence number. However, the overhead required to implement such a solution reduces storage capacity otherwise used for customer data. And, it would require significant modification to existing systems which are programmed to handle only a single, sequence number, field.
In alternative suggestions, the page number or the volume number may be added to the sequence number. However, in the former arrangement, every page N of every volume would have the same set of modified sequence numbers and in the latter arrangement, every page of a particular volume would have the same set of modified sequence numbers. If both the page number and volume number are added to the sequence number, aliasing may be avoided but performance would be degraded when data is transferred to the new arrangement because the sequence fields would have to be re-synthesized on the fly.
Consequently, it remains desirable to reduce sequence number aliasing without adversely affecting system performance.